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Abstract. This paper describes a translator called J AVA 
Pathfinder from Java to Promela, the “program- 
ming language” of the Spin model checker. The purpose 
is to establish a framework for verification and debug- 
ging of Java programs based on model checking. This 
work should be seen in a broader attempt to make formal 
methods applicable “in the loop” of programming within 
NASA’s areas such as spare, aviation, and robotics. Our 
main goal is to create automated formal methods such 
that programmers themselves can apply these in their 
daily work (in the loop) without the need for specialists 
to manually reformulate a program into a different no- 
tation in order to analyze the program. This work is a 
continuation of an effort to formally verify, using Spin, 
a multi-threaded operating system programmed in Lisp 
for the Deep-Space 1 space craft, and of previous work 
in applying existing model checkers and theorem provers 
to real applications. 

Key words: Program verification - JAVA - model check- 
ing - Spin - concurrent programming - assertions - 
deadlocks! 




1 Introduction 

In this paper we describe Java PathFinder (Jpf), a 
translator from Java to Promela^ the programming 
language of the Spin model checker. The purpose is 
to establish a framework for verification and debugging 
of Java programs based on model checking. The work 
should be seen in a broader attempt to make formal 
methods applicable “in the loop” of programming within 
NASA’s areas such as space, aviation, and robotics. Our 
main long term goal is to create an automated formal 
methods workbench for Java programming such that 
programmers themselves can apply them in their daily 
work (in the loop) without the need for specialists to 
manually reformulate a program in a different notation 
in order to analyze it. 

The tool we are developing is named after the rover 
operating on Mars in 1997 called the “Mars PathFinder” . 
Although this mission was generally regarded as a big 
success, the rover did in fact contain a number of soft- 
ware bugs (causing repeated rebootings and panic at 
NASA headquarters) that could potentially have been 
found beforehand using proper verification tools. The 
Java Pathfinder name is a play on words: it finds the 
paths of a Java program that lead to errors. 

Java [6,1] is a general purpose object-oriented pro- 
gramming language with built in mechanisms for multi- 
threaded programming [16]. It was originally designed to 
support internet programming, but goes well beyond this 
domain. Java is a relatively simple language compared 
to C-I- + , and it is regarded as a much safer language, 
amongst other things due to its automatic garbage col- 
lection and lack of general pointers. In spite of its sim- 
plicity it appears to be a powerful language. 

Spin [15] is a verification system that supports the 
design and verification of finite state asynchronous pro- 
cess systems. Programs are formulated in the Pro me la 
programming language, which is quite similar to an or- 
dinary programming language, except for certain non- 
deterministic specification oriented constructs. Processes 
communicate either via shared variables or via message 
passing through buffered channels. Properties to be veri- 
fied are stated as assertions in the code, or ^LS formulae in 
the linear temporal logic Ltl. The Spin model checker 
can automatically determine whether a program satis- 
fies a property, and, in ca.se the property does not hold, 
generate an error trace. Spin also finds deadlocks. 

In an earlier effort we formally verified, using Spin, 
a multi-threaded operating system for a spacecraft [9]. 
The operating system is one component of NASA’s New 
Millennium Remote Agent (RA) [17], an artificial in- 
telligence based spacecraft control system architecture 
launched October 24, 1998, as part of the Deep-Space 1 
mission to an asteroid to validate the potential of arti- 
ficial intelligence, ion propulsion, and other technologies 
for future space crafts. The operating system is imple- 
mented in a multi-threaded version of Common Lisp. 


The verification effort consisted of hand translating parts 
of the Lisp code into the Promela language of Spin. A 
total of 5 errors were identified, a very successful result. 

It is often claimed that model checkers of today can- 
not handle real sized programs, and consequently can- 
not handle real sized Java programs. This is certainly 
true. However, there are two aspects that make our ef- 
fort worthwhile anyway. First, by providing an abstrac- 
tion workbench we will make it possible to cut down the 
state space of a Java program. Second, one can imag- 
ine model checking being applied for unit testing, where 
one focuses on a single class (or a few classes) and puts 
this (these) in parallel with an aggressive environment 
represented by a number of threads. Finally, Java can 
be used as a design language, just as Promela. 

Few attempts have been made to automatically ver- 
ify programs written in real programming languages. 
The most recent attempt we can mention is the one re- 
ported in [2], which also translates Java programs into 
Promela, however not handling exceptions or polymor- 
phism as we do. The work in [3] defines a translator from 
a concurrent extension of a very limited subset of C-f+. 
The drawback of this solution is that the concurrency 
extensions are not broadly used by C-I-+ programmers. 
In [5] is described what is called Extended static check- 
ing, a technique for detecting, at compile-time, common 
programming errors. The technique uses program ver- 
ification technology, but feels to a programmer like a 
type checker. By using an underlying automatic theorem 
prover, the technique is more semantically thorough than 
decidable static analysis techniques. At the same time, 
by only trying to detect certain kinds of errors, not prove 
the program’s correctness, the technique is more auto- 
matic than program verification. Finally, [4] describes a 
theory of translating Java to a transition model, making 
use of static pointer analysis to aid virtual coarsening, 
which reduces the size of the model. 

A significant subset of Java version 1.0 is supported 
by Jpf : dynamic creation of objects with data and meth- 
ods, class inheritance, threads and synchronization prim- 
itives for modeling monitors (synchronized statements, 
and the wait and notify methods), exceptions, thread 
interrupts, and most of the standard programming lan- 
guage constructs such as assignment statements, condi- 
tional statements and loops. However, the translator is 
still a prototype and misses some features, such as pack- 
ages, overloading, method overriding, recursion, strings, 
floating point numbers, static variables and static meth- 
ods, some thread operations like suspend and resume, 
and some control constructs, such as the continue state- 
ment. In addition, arrays are not objects as they are in 
Java, but are modeled using Promela’s own arrays to 
obtain efficient verification. Finally, we do not translate 
the predefined class library. 

Note that many of these features can be avoided by 
small modifications to the input code. In addition, the 
tool is currently being improved to cover more of Java. 



Despite the omissions, we expect the current version of 
JPF to be useful on a large class of software. A front- 
end to the translator checks that the program is in the 
allowed subset and prints out error messages when not. 
The translator is developed in COMMON LiSP, having a 
Java parser written in MoscowML as front end. Ger- 
ard Holzmann supported our efforts by changing the se- 
mantics for the Promela unless construct in order to 
simplify the translation of exceptions. 

The paper is organized around an example Java pro- 
gram that has been translated automatically by Java 
Pathfinder and verified automatically by Spin. In Sec- 
tion 2 we describe this program, a bounded buffer. In 
Section 3 we describe what the resulting Promela code 
looks like. In Section 4 we present an experiment where 
we seeded 21 errors into the example program, and ran 
the Spin model checker on the code generated by JPF. 
Section 5 ends with conclusions and suggestions for fu- 
ture work. 


2 The Bounded Buffer Program 

The translation scheme will be illustrated by translation 
of a complete, small, but non-trivial Java program that 
covers many of the features of Java that we can trans- 
late. After translation by JpF, Spin can be applied to 
prove or disprove that the program satisfies given prop- 
erties stated as assertions in the program, and that it is 
deadlock free. 

2.1 The Buffer Class 

The Java program that we are interested in verifying 
properties about is a bounded buffer, represented by a 
single class. An object of this class can store objects of 
any kind (objects of subclasses of the general top level 
class Object). Figure 1 shows the declared interface of 
this class. It contains a put method, a get method and 
a halt method. Typically there will be one or more pro- 
ducer threads that call the put method, and one or more 
consumer threads that call the get method. The halt 
method can be invoked by a producer to inform con- 
sumers that it will no longer produce values to the buffer. 
Consumers are allowed to empty the buffer safely after 
a halt, but if a consumer calls the get method after the 
halt method has been called, and the buffer is empty, an 
exception object of class HaltException will be thrown. 
A class is an exception class if it is a subclass of the class 
Throwable. In particular, class Exception is a subclass 
of Throwable. 

Figure 2 contains the Buffer class annotated with 
line numbers for later reference. A Java class is gener- 
ally speaking described by a name, a set of data vari- 
ables, zero or more constructor methods (with different 
argument types if more than one) with the same name 


class HaltException extends Exception!} 

interface Bufferlnterf ace { 
public void put (Object x) ; 
public Object getO throws HaltException; 
public void haltO; 

} 

Fig. 1. The Java Buffer interface 

as the class, and a collection of methods. One of the con- 
structors is executed when an object is created with the 
new construct. Note that the Buffer class has no such 
user-defined constructors. The class declares an array of 
length 3 to hold the objects in the buffer. A cleaner way 
of writing this program would be to declare a constant 
‘^final int SIZE = 3^’ and then refer to SIZE rather 
than to 3 throughout the program. The translator, how- 
ever, currently requires an integer literal as the dimen- 
sion of an array. In addition to the array, a couple of 
pointers are declared, one pointing to the next free loca- 
tion, and one pointing to the next object to be returned 
by the get method. The variable usedSlots keeps track 
of the current number of elements in the buffer. Finally, 
the variable halted will become true when the halt 
method is called. 

The three methods of the class are all synchronized 
(note the synchronized keyword). Hence, each of these 
methods wall have exclusive access to the object when 
executed. That is, when one of these methods is called 
on the buffer object by a thread, the buffer gets locked 
to serve that thread, and it is unlocked again at the end 
of the method call. The put method takes as parameter 
the object to be stored in the buffer and has no return 
value (void). It enters a loop testing whether the buffer 
is full (i.e. having 3 elements) in which case it calls the 
built in wait method. Calling the wait method within 
a synchronized method suspends the current thread and 
allows other threads to execute synchronized methods on 
the object. Such another thread can then call the notify 
method which wall wake up an arbitrarily chosen waiting 
thread to continue past its wait() call. The notifyAll 
method wakes up all such waiting threads. 

The call of wait is put inside a try construct, which 
is Java’s exception handling construct. A general try 
construct has the form: 

try T 

catch(El el) Cl 

catch(E2 en) Cn 

finally F 

where each T,C1 , . . . ,Cn,F is a block (a statement or a 
sequence of statements enclosed by {...}) and each Ei is 
an exception type (class). The body T of the try state- 
ment is executed until either an exception is throwm or it 
finishes successfully. If an exception is throwm, the catch 



1. class Buffer implements Buf ferinterface { 

2. protected Object [] array = new Object [3]; 

3. protected int putPtr = 0; 

4. protected int getPtr = 0; 

5. protected int usedSlots = 0; 

6. protected boolean halted; 

7. 

8. public synchronized void put (Object x) { 

9. while (usedSlots == 3) 

10. try {waitO ;} 

11. catchdnterruptedException ex) {}; 

12. array [putPtr] = x; 

13. putPtr = (putPtr + 1) % 3; 

14. if (usedSlots == 0) notifyAllO; 

15. usedSlots++; 

16. } 

17. 

18. public synchronized Object get() 

19. throws HaltEiceptionf 

20. while (usedSlots == 0 ft ! halted) 

21 . try {wait () ; } 

22. catchdnterruptedException ex) {}; 

23. if (usedSlots == 0) { 

24. throw (new HaltExceptionO ) ; 

25. }; 

26. Object X = array [get Ptr] ; 

27. array [getPtr] = null; 

28. getPtr = (getPtr + 1) 3; 

29. if (usedSlots == 3) notifyAllO; 

30. usedSlots — ; 

31. return x; 

32. } 

33. 

34. public synchronized void halt(){ 

35. halted = true; 

36. notifyAllO; 

37. } 

38. } 

Fig. 2. The Java Buffer class 


clauses are examined from top to bottom in order to find 
one where the thrown exception is of the corresponding 
class Ei or of a subclass thereof. If such a catch is found, 
the corresponding block Ci is executed. If no appropri- 
ate catch is found, the exception “flows out” of the try 
statement into an outer try that might handle it. There 
can be any number of catch clauses in a try including 
none. If no catch clause in the method catches the ex- 
ception, the exception is thrown to the code that invoked 
this method. If a finally clause is present in a try, its 
code is executed after all other processing in the try is 
complete. This happens no matter how the completion 
was achieved, whether normally, through an exception, 
or through a control flow statement like return. 

Normally an exception is thrown explicitly within a 
thread using the throw (e) statement, where e is an ex- 
ception object (a normal object of an exception class 
which may include data and methods). However, one 
thread S may throw an exception in another thread T by 


class Main { 

public static void main (String [] args) { 
Buffer b = new BufferO ; 

Producer p = new Producer (b) ; 

Consumer c = new Consumer (b) ; 

} 

} 

Fig. 3. The Java main program 


executing T. interrupt () , which throws an 
InterruptedException, or T.stopO, which throws a 
ThreadDeath exception. The try construct around the 
wait call is supposed to catch exactly such interrupts 
from other threads. As we sec, nothing is done in this 
case (lines 11 and 22), but the try statement is neces- 
sary in order for the Java type checker to accept the 
program. We shall later see a real use of exceptions. One 
of the main results in this paper is that we can in fact 
prove properties of programs that throw exceptions. 

When finally the put method gets past the while 
loop, it is known that the buffer has free space, and the 
insertion of the new object can be completed. In case 
the buffer was in fact empty, all waiting consumers are 
notified. 

The get method is a little bit more complicated be- 
cause it also takes into account whether the buffer has 
been halted. Basically, it will wait until there is some- 
thing in the buffer, and return this element, unless the 
buffer is empty and at the same time has been halted. 
In this case, a HaltException is thrown. Otherwise, the 
next buffer element is returned, and producers are noti- 
fied if the buffer beforehand was full, in which case they 
may be waiting. 

2.2 Setting up an Environment 

In order to verify properties about this class, without 
looking at a complete application within which it oc- 
curs, we can create a small application using the buffer. 
We say that we set up an environment con.sisting of a 
number of threads accessing the buffer, and then we 
prove properties about this small system. This can be 
regarded as unit testing the buffer. Concretely, we shall 
define two thread classes: a Producer and a Consumer 
class, and then start the whole system as shown in the 
main method in Figure 3. 

First, in order to illustrate the translator’s capabili- 
ties to translate inheritance, we define the objects that 
are to be stored in the buffer, see Figure 4. A class 
Attribute is defined, which contains one integer vari- 
able. The constructor method with the same name as 
the class takes a parameter and stores it in this variable. 
The class AttrData extends this class with another field, 
and defines a constructor, which takes two parameters, 
and then calls the super class constructor with the first 
parameter. 



class Attribute{ 
public int attr; 

public Attribute (int attr){ 
this. attr = attr; 

} 

} 

class AttrData extends Attribute{ 
public int data; 

public AttrDataCint attr, int data){ 
super (attr) ; 
this. data = data; 

} 

} 

Fig. 4. The Java Attribute and AttrData classes 


The producer and consumer threads that are actu- 
ally going to use the buffer are defined in Figure 5. The 
Producer class extends the Thread class, which means 
that it must have a run method, which is then executed 
w^hen an object of this class is started with the start 
method. As can be seen, the constructor of the class in 
fact calls this start method in addition to storing locally 
the buffer for which elements will be produced. The run 
method adds 6 AttrData objects to the buffer, with at- 
tributes 0 ... 5 (in that order) and squares as data, and 
then calls the halt method on the buffer. 

The Consumer class also extends the Thread class. 
The run method stores all received objects in the 
received array (or at most 10 of them). Note how the 
receiving loop is written inside a try construct, which 
catches and prevents a HaltException from going fur- 
ther. 

2.3 Property Specifications 

JPF allows a programmer to annotate his Java program 
with assertions and verify them using the Spin model 
checker. In addition, deadlocks can be identified. An as- 
sert statement is expressed as a call to the static method 
assert in the Verify class shown in Figure 6. The fact 
that it is static means that we can call this method di- 
rectly using the class name Verify as prefix, without 
making an object instance first. The body of this method 
is of no real importance for the verification since only 
the call of this method (and not its definition) will be 
translated into a corresponding Promela assert state- 
ment. A meaningful body, like printing an error message 
as in this example, can be useful during normal testing 
though, but it will not be translated into Promela. 

The first assertion in Figure 5 states that the con- 
sumer receives exactly 6 elements from the buffer. The 
second assertion within the for loop states that the re- 
ceived elements are the correct ones (at least wrt. the 
attr value). 


class Producer extends Thread { 
private Buffer buffer; 

public Producer (Buffer b) { 
buffer = b; 
this . start () ; 

} 

public void runO { 

for (int i = 0; i < 6; i++) { 

AttrData ad = new AttrData(i , i+i) ; 
buffer. put (ad) ; 
yieldO ; 

}; 

buffer .halt () ; 

} 

} 


class Consumer extends Thread { 
private Buffer buffer; 

public Consumer (Buffer b) { 
buffer = b; 
this . start 0 ; 

} 

public void runO { 
int count = 0; 

AttrData [] received = new AttrData [10] ; 
try{ 

while (count < 10) { 

received [count] = (AttrData)buf fer , get () ; 
count++ ; 

} 

} 

catchOialtException e){}; 

Verify . assert (count == 6); 
for (int i = 0; i < count; i++){ 

Verify.assert (received[i] .attr == i);l 

} 

> 

Fig. 5. The Java Producer and Consumer classes 
class Verify! 

public static void assert (boolean b){ 
if (!b) 

System. out .println ("assertion broken") ; 

} 

} 

Fig. 6. The Java Verify class 


One can consider other kinds of Verify methods, in 
general methods corresponding to the operators in Ltl, 
the linear temporal logic of Spin. Since these methods 
can be called wherever statements can occur, this kind of 
logic represents what could be called an embedded tempo- 
ral logic. As an example, one could consider a statement 
of the form: Verify .eventually (count == 6) inserted 



#define Index byte 
#define MAX .OBJECT 7 

typedef Attribute.ClassI 
int attr; 

}; 

Attribute.Class Attribute.Obj [MAX.OBJECT] ; 

Index Attribute.Next = 0 ; 

typedef AttrData_Class{ 
int attr; 
int data; 

}; 

AttrData.Class AttrData.Obj [MAX.OBJECT] ; 

Index AttrData.Next * 0; 

Fig. 7. Object arrays for the Attribute and AttrData classes 


as the second statement of the consumer run method. 
The major advantage of this approach is that we do 
not need to change the Java language, or parse spe- 
cial “specification comments’’ . J AVA itself is used as the 
specification language. Note, however, that at this point, 
only the assert method is supported. 


3 Translation 

3.1 Classes, Inheritance and Object Creation 

The general principle behind the translation is the fol- 
lowing. A Java class basically consists of data variables 
and methods. For each new creation of an object, a new 
set of data variables, a data area, is allocated, and the 
methods of that object will then work on this newly allo- 
cated area. Hence, at any point in time a set of data areas 
will have been allocated, one for each object not garbage 
collected. We shall model the set of data areas of a class 
by an array of records (typedef ’s in Spin terminology), 
one record for each data area. An index variable will 
point to the next free record in the array, initially having 
the value 0 (first record in the array). Method definitions 
are mapped into macro definitions, and method calls are 
mapped into applications of macros. Note that the trans- 
lated code shown is the unedited Pro MEL A code gener- 
ated by the translator (except for a couple of omissions). 

For illustration, we start with the translation of the 
simplest classes, namely Attribute and AttrData, which 
have no methods, but which show inheritance. Figure 7 
shows the data areas for the two classes. For each class 
C an array named C_0bj is defined of size MAX.OBJECT 
and of type C_Class. In addition, a pointer C.Index to 
the next free data area (object) is declared. Because the 
AttrData class inherits from the Attribute class, it in- 
cludes the attr variable in addition to the data variable. 

Note that this translation puts a limit (MAX.OBJECT) 
on the number of objects that can be created of a class. 


#define Attribute 6 
#define AttrData 7 

#define create_object (c , i) 

(c*i00 + i) 

#define get_class(x) 

(x/100) 

#define get^index(x) 

(x - ((x/100) *100)) 

Fig, 8, General object reference operations 

A particular object is now referenced by an object ref- 
erence containing information about which class it con- 
cerns (and thereby which array) and which instance (in- 
dex in the array) it concerns. Because Pro MELA ’s record 
concept (typedefs) is not flexible enough for our needs 
(e.g., field access cannot be applied to a conditional ex- 
pression) we have decided to represent an object ref- 
erence (c, i) as the integer c * 100 -I- i. The operations 
(macros) for dealing with these calculations are shown 
in Figure 8. Each class is given a unique identification 
which is a number, for example class Attribute is given 
number 6. 

In order to access the variables in these arrays, macros 
are defined as shown in Figure 9. These macros are pre- 
fixed with the name of the class that defines the vari- 
able, which is statically decidable in Java at the point 
w'here the variable is accessed (in contrast to method 
calls). However, because Java supports polymorphism 
where an object may belong to a subclass of the stati- 
cally declared class (for example if it is a parameter to a 
method) we need to define these variable accessors such 
that they access the right array. For example, the macro 
Attribute.get_attr for reading the attr variable de- 
fined in the Attribute class is defined as a conditional 
expression over the subclasses. 

Both classes have constructors which will be executed 
when creating new objects. For example, the Java ex- 
pression “new AttrData (2 ,4)” will cause a call of the 
constructor, which in turn will call the constructor of 
the super class: “Attribute (2)”. Constructors are mod- 
eled as macros as shown in Figure 10 (slightly simpli- 
fied for presentation purposes; the real trainslation also 
takes into account variable initializations occurring to- 
gether with variable declarations). The parameter obj 
will be an object reference denoting the object being 
constructed. 

The construction of a new object such as for ex- 
ample the Java statement “x = new AttrData (2, 4)” 
is mapped into the sequence of Promela statements 
shown in Figure 11 (slightly simplified here with respect 
to the treatment of the variable x): one can see how 
the X is bound to a reference, the next-pointer is incre- 


#define undefined 0 

#define Attribute_get_attr(obj) 

(get.class (obj) == AttrData “> 

AttrData_Obj [get_index (obj )] . attr : 

(get_class (obj) == Attribute -> 

Attribute^Ob j [get^index (obj ) ] . attr : 
undefined) ) 

#def ine Attribute^set^attr (obj , value) 
if 

: : get^class (obj) == AttrData -> 

AttrData_Obj [get_index (obj)] . attr = value 
• ' get_class (obj) == Attribute -> 

Attribute_Obj [get_index(obj)] . attr = value 
fi 

#define AttrData_get_data(obj) 

AttrData^Obj [get_index(obj)] .data 

#def ine AttrData_set_data(obj .value) 

AttrData_Obj [get_index (obj)] . data = value 

Fig. 9. Variable accessors for the Attribute and AttrData classes 

#def ine Attribute_constr (obj , attr) 
Attribute_set_attr (obj .attr) ; 

#def ine AttrData_constr(obj , attr, data) 
Attribute_constr (obj , attr) ; 

AttrData_set_data(obj .data) ; 

Fig. 10. Constructors for the Attribute and AttrData classes 
atomic! 

X = create_object (AttrData, AttrData_Next) ; 
AttrData_Next++ 

}; 

AttrData_constr(x,2,4) ; 

Fig. 11. Translation of x = new AttrData(2,4) 


merited, and the constructor is applied to the reference 
now stored in x. 

3.2 Synchronization on Objects 

The Buffer class is more complicated because it con- 
tains methods, and because these in addition are syn- 
chronized, which means that they must have exclusive 
access to the object when executing. That is, only one 
thread at a time may execute any synchronized method 
on the same object. Therefore, the translation must pro- 
vide a locking mechanism with which one can lock an 
object to serve a particular thread that calls a synchro- 
nized method on the object. For that purpose some extra 
variables are inserted into the data area of each object, 
as shown in Figure 12. In addition to the variables de- 
clared in the class (note that Java arrays are modeled 
directly as Promela arrays), it contains the three vari- 


typedef Buf fer_Class{ 
int LOCK; 
byte WAITING; 
chan WAIT = [0] of {bit}; 

Obj Ref array [3] ; 
int putPtr; 
int getPtr; 
int usedSlots; 
bit halted; 

}; 

Fig, 12. Object type for the Buffer class 

#define Buf fer_any_WAITING(obj) 

Buffer_0bj [get .index (obj)] .WAITING > 0 

#define Buf fer_incr_WAITING(obj) 

Buffer.Obj [get. index (obj)] .WAITING++ 

#define Buff er.decr.WAITING (obj) 

Buffer.Qbj [get. index (obj)] .WAITING— 

Fig. 13. Operations on WAITING 

ables LOCK, WAITING and WAIT used for managing ob- 
ject locking and release. The LOCK variable will at any 
time either be null (a negative integer) or it will be the 
thread id of the thread that currently is executing a syn- 
chronized method on the object (actually a non-negative 
Promela process id). Hence, once this field is set to a 
proper thread id by a thread that calls a synchronized 
method, only the thread with this thread id is allowed to 
operate on the object. When the call of the synchronized 
method terminates, the lock is released by setting it to 
null again. Note that a synchronized method must be 
allow^ed to call other synchronized methods on the same 
object without causing blocking. 

The variables WAITING and WAIT are used to man- 
age threads that call the wait, notify, and notifyAll 
methods on the object. A thread that calls waitO will 
first unlock the object, and then try to read a value on 
the zero place channel WAIT. A zero place channel in 
Promela is used to model rendezvous communication, 
hence some other thread must send a value on this chan- 
nel in order for the calling thread to be released. At any 
time, all threads that are waiting to get access to the 
object are waiting on this channel. Each time a thread 
calls the wait () method on the object, the WAITING vari- 
able is additionally incremented, and conversely decre- 
mented when released. Hence, the value of this variable 
will always be the number of threads waiting on the ob- 
ject. The variable is used when notifyAll is called by a 
thread, and all waiting threads have to be released: we 
need to know how many times the WAIT channel must 
be signaled. The operations on the WAITING variable are 
shown in Figure 13. 

Locking and unlocking an object is implemented by 
the operations shown in Figure 14. Locking an object 



#define this _pid 


#define continue 0 


#define Buf fer_lock(obj) 
atomic{ 

Buffer_get.LOCK(obj) == null -> 

Buff er_set_LOCK(obj ,this)} 

#define Buffer_unlock(obj) 

Buffer_set_LOCK(obj ,null) 

Fig. 14. Operations for locking and unlocking objects 


is done when a thread calls a synchronized method on 
an object which the thread has not already locked. First 
the thread waits until the lock becomes free (no other 
thread has locked it), which is the case when the LOCK 
field becomes null. Note that in Promela, an equality 
is a statement that is executable only when the equality 
holds, and hence blocks until this is the case. Then, in an 
atomic move, the thread locks the object by assigning the 
value of “this” to the LOCK field, where “this” denotes 
the thread id of the current thread (“this” is defined as 
.pid, which in PROMELA refers to the process id of the 
currently executing process). Unlocking an object just 
corresponds to setting the LOCK field to null. 

Finally, the macros modeling the wait, notify and 
notifyAll methods are shown in Figure 15. The 
Buffer_wait macro models the wait method. Ignore 
for a moment the unless constructs. When called, it 
first unlocks the object, because other threads should 
now have access to perhaps later call notify. Then the 
WAITING field is increased, and finally the thread starts 
waiting for a signal (the value 0) on the WAIT channel. 
When the thread is woken up by a notify or notifyAll, 
it locks the object again (first occurring call of 
Buf fer_lock(obj)) in order to continue with exclusive 
access to the object (note that wait can only be called 
within a synchronized context in Java). 

The Bufferjiotify macro signals the WAIT chan- 
nel in case there are threads waiting for a signal. The 
Buf fer jiotifyAll macro does this as long as there are 
threads waiting. Note that this happens atomically so 
that no new threads can join the waiting threads during 
the notification. 

Now we explain the unless constructs in the 
Buf f er.wait macro. This extra complication is caused 
by the fact that another thread can either interrupt or 
stop a thread that is waiting. Recall that such an inter- 
rupt or stop is like an exception being thrown inside the 
(perhaps waiting) thread being interrupted or stopped. 
We shall later explain exceptions in more detail, but here 
it suffices to say that in case such an exception is thrown, 
the waiting thread must be released immediately; this 
occurs because the conditions of the two unless con- 
structs become true. 

Suppose that the waiting thread is blocked in the 
“Buffer^et_WAIT(obj)?continue” statement, and that 


#defin€ Buf fer.wait (obj) 
atomic! 

{ 

Buff er_unlock(obj) ; 
Buffer„incr_WAITING(obj) ; 

Buf f er_get_WAIT (obj) ?continue 

} 

unless! 

d_step! 

get_this_EXN > 0 -> 

Buf fer_decr_WAITING(obj) 

} 

}; 

Buffer_lock(obj) 

} 

unless !a_f inally (Buff er.lock(obj) ) } 

#define Buffer_notify(obj) 
atomic! 
if 

:: Buf fer.any .WAITING (obj) -> 

Buff er.get .WAIT (obj) ! continue; 

Buff er.decr.WAITING (obj) 

: : else -> skip 
fi> 

#define Buffer.notifyAll (obj) 
atomic! 
do 

: : Buf fer.any.WAITING(obj) -> 

Buffer_get_WAIT(obj) ! continue; 

Buf fer_decr_WAITING(obj) 

: : else -> bre 2 ik 
od} 

Fig. 15. The operations wait, notify and notifyAll 


such an interrupt occurs. Then (due to the new seman- 
tics of the Promela unless construct, see Section 3.5) 
the inner unless construct will be triggered since, as we 
shall see, this implies that get_this_EXN becomes bigger 
than zero. This causes the WAITING variable to be decre- 
mented, which is necessary because the Buf f er_notify 
and BufferjiotifyAll macros normally do this (and 
now have not had the chance to do it). Next, because 
the waiting thread may have code in finally constructs 
that must be executed before termination (not shown 
here), it is necessary to lock the object again before stop- 
ping such that this finalize code can be executed with 
exclusive access to the object. This is done by the out- 
ermost unless construct. It was necessary to introduce 
two unless constructs since the interrupt may also ar- 
rive after the thread has been woken up, but while it is 
w’aiting for the lock to be released; that is, it is waiting 
in the first occurring Buffer_lock(obj) statement. 



#define Buff er.halt (obj) 
if 

: : Buff er_get_LOCK(obj) == this -> 

Buf f er_halt_code (ob j ) 

: : else -> 

Buffer_lock(obj) ; 

try (Buf f er_halt_code (obj) ) 

unless {d_f inally(Buffer_unlock(obj) )} 
fi 

#define Buff er_halt_code (obj) 

Buff er_set_halted(obj ,true) ; 

Buf fer_notifyAll(obj) 

Fig. 16. Translation of the halt method 


3.3 Methods 

In order to illustrate how methods are modeled^ we illus- 
trate the simplest one, namely the halt method. A syn- 
chronized method M in a class C is defined in two parts: 
a C_M macro dealing with object locking, and a C Jt^code 
macro containing the actual code of the method. For 
non-synchronized methods there is no such distinction. 
This is shown for the synchronized halt method in Fig- 
ure 16. In general, a method call is translated into a call 
of the C_M macro with parameters corresponding to the 
method parameters. In the case of halt, the method is 
parameterless, hence only the object reference of the ob- 
ject upon which the method is called is given as parame- 
ter. The macro tests whether the object is already locked 
by the calling thread, in which case the actual code, 
C_M_code, is executed. This models the situation where 
this method is called by another synchronized method, 
hence the object is already locked. In case the object 
is not locked by the calling thread, an attempt is made 
to lock it (Buf fer-lock(obj)), and after successful lock- 
ing, the code is executed. The try macro models the try 
construct of Java and models the fact that the object 
must always be unlocked (Buffer_unlock(obj)) when 
leaving the method, also in the case where an exception 
is raised during execution of the code. 

3.4 Threads 

It remains to explain how things are put together by 
translating the main method and the threads that it 
starts. First, we describe how the thread classes Producer 
and Consumer are translated. We focus on the Producer. 
Thread classes are translated in a similar manner to 
other classes, with the addition that the run method 
is translated into a Promela process type (proctype), 
that can then be started using the Promela run state- 
ment, whenever a corresponding Jav^a thread is started 
with the Java start method. Figure 17 shows the trans- 
lation of the run method of the Producer class of Figure 
5. 


proctype Producer_Thread(ObjRef obj){ 

f 

int Producer_run_i ; 

ObjRef Producer_run_ad; 

ObjRef Buffer_put_ex; 

Producer_riin_i = 0; 
do 

: : (Producer_run_i < 6) -> 
atomic! 

Producer_run_ad “ 

create_object (AttrData, AttrData_Next) ; 
AttrData_Next++} ; 

AttrData_constr (Producer_run_ad , 
Producer_run_i , 

(Producer_run_i ♦ Producer_run_i) ) ; 
Buffer_put (Producer_get_buf fer(obj) , 
Producer_run_ad) ; 

Producer_run_i = (Producer_run_i + 1) ; 

: : else -> break 
od; 

Buf fer_halt (Producer_get_buf fer (obj ) ) ; 

} 

unless {get_this_EXN > 0} 

} 

Fig. 17, The Producer run method 


The process takes as parameter its own object ref- 
erence. Notice how local variables in called methods are 
declared as global variables in the process. For example, 
the variable ex in the put method that binds the caught 
exception in the try statement (Figure 2) is declared 
at this point. This is necessary because Promela does 
not support local variables (nor does it in the new inline 
procedures that Promela got recently). This solution 
of course prevents the translation of recursive methods, 
but it is efficient with respect to verification time since 
we don’t need to maintain a call stack (and represents 
what one normally would do in a hand translation). An- 
other possibility is to translate methods into proctypes, 
as suggested in [15], but experiences during earlier work 
suggested that this would be inefficient, see [9]. The while 
loop is translated into Promela’s do ... od construct 
in a very straight forward way. 

Note in Figure 17 how the object reference to the 
buffer in the buffer variable declared inside the Producer 
class is accessed and passed as argument to the put and 
halt methods. This models the dot-notation in Java for 
accessing methods in an object. Surrounding the pro- 
ducer thread code is an unless construct, which is sup- 
posed to catch any exceptions thrown and not caught 
by the user program. This will be explained in the next 
section. Finally, Figure 18 shows the translation of the 
Producer object constructor. It shows how the buffer 
variable is initialized with the argument, and how the 
process is started, corresponding to the “this . start () ” 
call. 



#define Producer.constr (obj ,b) 
Producer_set_buff er(obj ,b) ; 
run Producer_Thread(obj) ; 

Fig. 18. The Producer constructor 


3.5 Exceptions 

Java exceptions are complicated when considering all 
the situations that may arise, such as method returns 
in the middle of try constructs, the finally construct, 
interrupts (which are exceptions thrown from one thread 
to another) of threads that have called the wait method, 
and the fact that objects have to be unlocked when an 
exception is thrown out of a synchronized method. We 
shall try to illustrate our solution. 

Promela’s unless construct seems very closely re- 
lated to an exception construct, except for the fact that 
it works “outside in” instead of “inside ouV\ the latter 
being the case for exceptions. As an example consider 
the Java statement (assuming some variable x): 

tryf 

try{throw(new ExceptionO ) ; } 

catch (Exception e){x = 1;} 

} 

catch(Exception e){x = 2;} 

The result of executing this statement should be that 
X is assigned to 1, hence (only) the inner catch is invoked 
when the exception is thrown. In contrast, consider a re- 
lated Promela statement, where now an EXN variable 
(initially 0) has been introduced. When this variable be- 
comes positive it is regarded as if an exception has been 
thrown: 

{ 

{EXN = 1} 

unless {EXN > 0 -> x = 1} 

} 

unless {EXN > 0 -> x = 2} 

The effect of this statement will be that x is as- 
signed to 2. Hence, the outermost unless construct is 
invoked when EXN becomes positive. Gerard Holzmann 
has been very helpful to us by implementing a - J option 
(J for Java) in the verifier that changes the semantics 
of Promela in such a way that unless constructs are 
interpreted “inside ouf. This still leaves a second issue: 
that as soon as the inner unless is chosen (executing 
the inner EXN > 0), then the outer is invoked (since EXN 
> 0 is still true) and x gets the value 2 anyway. Hence, 
we have to prevent that kind of behavior. Note that the 
above Promela code needs some modifications to ac- 
tually “work” because if it is the last statement in “P” 
within the statement “P unless Q” that makes “Q” ex- 
ecutable, then “Q” will actually not get executed. 

Recall that a Java exception is an object of one of 
the exception classes, either one of the built in or a user 


typedef Consumer_Class{ 

Ob j Ref EXN; 

ObjRef buffer; 

}; 

Fig, 19. The Consumer object type 

#define exn_Exception 

(get_class (get_this_EXN) == Exception 
1 exn_InterruptedException 
1 exn_HaltException) 

Fig. 20. The exn_Exception predicate 

#define dotted_throw(obj ,exn) 
set_EXN(obj ,exn) 

#define throw (exn) 

dotted_throw(obj ,exn) 

#define stop(obj) 

dotted_throw(obj ,THREAD_DEATH) 

Fig. 21. Operations for throwing exceptions 


defined exception class. Hence, an exception may con- 
tain data and methods. The throw (e) statement takes 
an exception object reference e as argument, and in our 
model we translate that into a store of that object ref- 
erence in a special variable, EXN, in the data area of 
the thread (potentially the main program) where it has 
been thrown. All the unless constructs in the thread will 
test on this variable to see if it becomes different from 
null. The data area for the Consumer class is shown 
in Figure 19. There are corresponding macros for ac- 
cessing this variable. There are macros get_EXN(obj) 
and set_EXN(obj , value) for accessing this variable of 
a thread identified by ob j . In addition, the macros 
get^this_EXN and set_this_EXN will access the EXN vari- 
able of this thread. 

For each exception class E, there is a predicate exn_E 
which evaluates to true if the EXN variable contains an 
exception object of that class or a subclass thereof. For 
example. Figure 20 shows this predicate for the built in 
Exception class. Recall that the HaltException was de- 
fined as a subclass thereof, as is InterruptedException. 

Exception throwing is mainly modeled by the macros 
shown in Figure 21. The dotted_throw macro throws 
an exception at a particular object given as parame- 
ter. This allows one thread to throw an exception at 
another thread, causing that other thread’s EXN variable 
to be set. The throw macro throw^s an exception to the 
object identified by the free variable obj which is this 
current thread object. Finally, calling “T.stopO” in a 
Java program corresponds to throwing the predefined 
THREAD-DEATH exception object to the T object. 

We shall now explain how exceptions are caught. 
Consider a try statement of the form: 


{ try (Buffer^wait(obj)) 
unless { 
if 

: : catch (exn.InterruptedException, 

Buf f er_get_ex , skip) 

fi}; 

} 

unless {finally (skip)} ; 

Fig. 22. Translation of the try statement in the get method 


try T 

catch(El el) Cl 
catch(E2 e2) C2 

catch(En en) Cn 
finally F 

A Java statement of this form is translated into a 
Promela statement of the following form using macros 
defined in Figure 23, and where a prime (’) after a block 
indicates its translated version: 

{ try (TO 
unless { 
if 

:: catch(exn_El ,el ,C1 O 
:: catch(exn_E2 & ! exn^El ,e2 ,C2 O 

:: catch(exn_En & lexn^El & !exn_E2 & 

. . . & ! exn_En- 1 , en , Cn 0 
fi} 

} 

unless {finallyCFO} 

For example, the try construct in the get method 
in Figure 2 is translated into the Promela code in Fig- 
ure 22. The general idea behind this translation is that 
the inner unless construct catches any exceptions which 
match any one of the exception predicates exn_El . . . 
exn_En, and that the outer unless construct models the 
finally construct in Java: the block F must be exe- 
cuted no matter what as the last thing. For example, 
in the case where for example C 1 ’ itself throws a new 
exception, the F still has to be executed before that ex- 
ception can be thrown further up. Now, let us explain 
the macros in Figure 23. 

The try(s) macro executes s and then throws the 
predefined EXIT object (exit.to.f inal). The EXIT ex- 
ception is then caught by the finally macro (always in- 
serted at the end) as we shall see. The catch(exnT;,x, s) 
macro tests whether the current value of the EXN variable 
satisfies the exn_E predicate (catch_cond(exn_E,x)), in 
which case that branch is executed. 

The catch_cond(exnJE,e) macro in an atomic move 
tests the predicate exn_£ (hence is only executable when 
it is true, see Figure 20 for one such predicate), and then 
stores the value of the exception in the local variable e to 


^define try(s) 

{s;exit_to_f inal ; skip} 

#define exit_to_f inal 
throw (EXIT) 

#define catch(exn.E,x,s) 

catch_cond(exn_E,x) -> s ; exit_to_f inal 

#define catch_cond(exn_E,e) 
d_step{ 

(exn_E) 

-> 

® “ get_this_EXN; 
set^this_EXN(NO_EXN) 

} 

#define finally(s) 

final.cond “> sjexit^f inaljskip 

#define final_cond 
d_step{ 

get_this_EXN > 0 -> 
if 

: : get_this_EXN == EXIT -> 
set _this_EXN (NO.EXN) 

: : else -> 

set„this_EXN(” get^this^EXN) 

fi> 

#define exit_final 

set_this_EXN (- get_this_EXN) 

Fig. 23. Operations for catching exceptions 


be accessible within the block to be executed. Note also 
how the EXN variable is zeroed to the predefined N0_EXN 
value in order to avoid outer unless constructs being 
triggered, as already discussed earlier on page 10. 

The finally (s) macro defines w^hen the outer unless 
construct should be triggered, namely when f inal.cond 
becomes executable. The f inal_cond macro is executable 
whenever there is some exception object reference in the 
EXN variable (it is bigger than 0). Note that we reset this 
to 0 (N0_EXN) whenever an exception is caught at an in- 
ner level so that this outer final construct will not get 
activated. If there is an exception, and this is just a nor- 
mal EXIT from one of the blocks T, Cl , . . , ,Cn in the try 
statement, this is then forgotten (set.this_EXN (N0_EXN) ) 
If on the other hand (else) it concerns an exception 
that has not been caught, we need to remember it so 
that it can be re-thrown after the code in the finally 
construct has been executed. We also need to make sure 
that it does not activate unless constructs higher up 
during the execution of the finally code. One w'ay to 
do this is to negate it since the unless constructs in the 
translation only react on positive values of EXN. When 
we then leave the finally construct, we negate it back 
to its positive value such that it can be “thrown” fur- 


#define Buffer_get_code(obj) 

{ 

return_with(Buffer_get_x) ; 

} 

unless {return_cond} 

Fig. 24. Translation of the value returning get method 


ther up. Some of the macros contain skip statements. 
These are necessary in order to make it work due to the 
semantics of the unless construct. 

In Figures 15 and 16 the macros a_finally(s) and 
d_finally(s) are called. These are defined as respec- 
tively atomic{f inally(s)} and d_step{f inally(s)}. 

The d_f inally (Buf f erjunlock(obj) ) call in Fig- 
ure 16 unlocks the object in case an exception has been 
thrown out of a synchronized method. The d^step en- 
sures that the exception is not thrown further up during 
the unlocking (which is more economic than negating the 
exception) and the unlocking can be made completely 
atomic since there are no blocking statements. 

The a_f inally (Buffer JLock(obj)) call in Figure 
15 locks an object after a call of wait has been inter- 
rupted. This locking must be as atomic as possible, but 
with the possibility of blocking since another thread may 
own the lock. Therefore a d.step cannot be used (it does 
not allow blocking). 

3.6 Value Returning Methods 

A Java return statement can have one of two forms. 
Either it has the form “return” in case the method is 
not value returning, or the form “return exp'' if the 
method is value returning. In either case, such a return 
statement has the same effect as throwing an exception 
that is caught by a “return exception handler” surround- 
ing the body of the value returning method, and by any 
finally constructs on the “way up” to that. Figure 24 
shows how the get method of the Buffer cla^s translates 
with respect to value return. 

We see that the body of the method is surrounded 
by an unless construct triggered by the return.cond 
predicate. This predicate, defined in Figure 25, becomes 
executable when the EXN variable in the executing thread 
(the one that executes the value returning method) gets 
the value RETURN which is a predefined fixed object refer- 
ence. This happens for example when the return.with 
macro is called with an argument denoting the value re- 
turned. The return.without models the return from a 
method that does not return a value. 

The assignment “RES [TOP] = e” in the return.with 
macro needs some explanation. The problem we are faced 
with is that Java allows value denoting expressions to 
contain calls of value returning methods that may have 
side effects. In Promela expressions are of a syntacti- 
cally different class than statements, and cannot have 


#define return_with(e) 

RES [TOP] = e; 
throw (RETURN) 

#define return_without 
throw (RETURN) 

#define return_cond 
d_step{ 

get_this_EXN == RETURN -> 
set_this_EXN(NO_EXN) 

} 

Fig. 25. Operations for return exceptions 
#define MAX_RESULT 5 

proctype Consuiner_Thread(ObjRef obj){ 

int RES[MAX_RESULT] ; 
byte TOP; 

Buf f er_get (Consumer_get_buf f er (obj) ) ; 
Consumer_run_received [Consumer_run_ count] = 
RES [TOP] ; 

} 

Fig. 26. The Consumer thread 


side effects. Consider for example the following state- 
ment in the Consumer class’s run method: 

received [count] = (AttrData)buffer .get () ; 

Ignoring the casting “(AttrData) . . the right hand 
side of this assignment has side effects, whereas the right 
hand side of a Promela assignment does not allow this. 
Our solution is to execute the method before the assign- 
ment, and then store the result value in a result array 
that is introduced for this purpose. Note that it has to 
be an array in order to model assignment statements of 
the form “x = o.m(x) + p.n(y)” where several value 
returning method calls occur in an expression. Part of 
the translation of the Consumer class’s run method is 
shown in Figure 26. The Buf ferret macro will execute 
and finally store the return value in RES [TOP] , where 
RES is the result array. This value is then “picked up” in 
the assignment statement. Note that if there are several 
value returning method calls in a single expression, the 
TOP variable is incremented for each during their eval- 
uation, and then reset to its previous value before the 
values are accessed. 

3. 1 The main Method 

The main method of the Main class is translated into 
the Promela init section as can be seen in Figure 27. 
We have already explained the translation of object cre- 
ation, which is the only activity of this particular main 


init{ 

{ObjRef Main_main_b; 

Ob j Ref Hain_main_p; 

ObjRef Main_main_c; 
atomic{ 

ObjRef obj = create_object (Main,Main.Next) ; 
Main_Next++} ; 
atomic{ 

Main_main_b = 

create_ob ject (Buf f er ,Buf f er_Next) ; 

Buf f er_Next++} ; 

Buff er_constr(Main_main_b) ; 
atomic{ 

Main_main_p = 

create.object (Producer ,Producer_Next) ; 
Producer_Next++} ; 

Producer_constr (Main_main_p , Main_main_b) ; 
atomic{ 

Main_main_c = 

create_ob ject (Consumer , Consumer _Next) ; 
Consumer_Next++} ; 

Consumer_constr (Main_main_c ,Main_main_b) ; 

} unless {get_this_EXN > 0} 


Fig. 27. The main method 


method. Recall that the constructors of the Producer 
and Consumer classes in this present example start the 
processes. 


4 Analyzing the Program 

The presented program is correct in the sense that no 
errors are found by Spin when applied to the Promela 
code generated by JPF. In order to illustrate the effec- 
tiveness of JPF (and Spin of course) we have seeded 21 
errors in the program shown in Figure 2, and for each er- 
ror analyzed the now incorrect program using JPF. This 
experiment is described in the following. 

4 A The Result 

The results of this experiment are shown in Table 1. 
For each error we give the line numbers changed, refer- 
ring to Figure 2, and the new contents of these lines. 
As an example, error 1 is obtained by changing line 3 
to “protected int putPtr = 1;” (initializing to 1 in- 
stead of to 0). 

The results of applying JPF are shov.m in the fourth 
column. That is, the result of applying the Spin model 
checker to the Promela code generated by Jpf. The 
possible outcomes are deadlock (D) and any of the two 
assertions being violated (A1 referring to the first oc- 
curring “count == 6” and A2 referring to the second 
“received [i] .attr == i”). The point here is that all 
the errors are caught. 


The last two columns show the result of running the 
modified Java program on two versions of the Java Vir- 
tual Machine (Jvm) in order to see whether plainly ex- 
ecuting the program would highlight the errors seeded. 
Jvm version 1.1.3 is an older version being very deter- 
ministic. This means that executing a multi- threaded 
program several times typically yields the same result 
every time. JvM 1.1.6 is the newer version with na- 
tive threads, where Java threads are mapped to Solaris 
threads. This version is therefore non-deterministic, po- 
tentially yielding different results for different runs of a 
multi-threaded program. 

Every program has been run several times (from 30 
to 100), and the numbers indicate the percentage of runs 
that have highlighted the error, either via a deadlock, an 
assertion violation, or a thrown NullPointerException. 

All runs, model cHecking as well as JvM runs, have 
been executed on a Sun Ultra Sparc 60 with 512 Mb 
of main memory, and with the Solaris operating system 
version 5.5.1. 

Running the Spin model checker on the Promela 
code generated by JPF typically used less than half a 
second to find an error and explored between 40 and 400 
states and a similar number of transitions. In a few cases 
(error 8 and 10) approximately 10000 states and 18000 
transitions were explored in less than 2 seconds. The 
memory consumption was around 17 Mb. This amount 
of memory must probably be explained by the modeling 
of the Java Virtual Machine within Promela. 

“Errors” 11 and 20 are special (marked with a *) 
in the sense that they are not really errors when us- 
ing the environment described in Section 2.2. This en- 
vironment only creates one consumer, and to make the 
errors manifest themselves, we needed to create two con- 
sumers. In addition, with two consumers the assertions 
make no sense and were deleted. Hence, we were now 
just looking for deadlocks. The table rows for these er- 
rors show the result of verifying and executing in this 
changed multi-consumer environment. The verification 
of error 11 needed as much as 8 minutes and 77 Mb, 
exploring 2.4 million states and 6 million transitions be- 
fore the deadlock was found. We verified a down scaled 
version of this error, with a buffer size of 2 (instead of 3) 
and the producer only producing 3 values (instead of 6). 
Also here the deadlock was found by the model checker, 
but now using 1 minute, 28 Mb, and exploring 423096 
states and 1 million transitions. 

Spin used 5.2 seconds to verify that the original pro- 
gram contained no errors. This involved the exploration 
of 33683 states and 61944 transitions, and a memory 
consumption of 18.8 Mb. 

4.2 Comments on the Result 

The example is small since its main purpose has been 
to illustrate the translation done by Jpf. However, the 
exercise does show that around half (11) of the errors 


Table 1. Verification results 


Nr. 

Line 

Modification (changed to) 

JPF 

JVM 1.1.6 

JVM 1.1.3 

1 

3 

protected int putPtr = 1; 

A2 

100 

100 

2 

5 

protected int usedSlots = 1; 

Al, A2 

100 

100 

3 

9 

while (usedSlots != 3) 

D 

100 

100 

4 

9 

while (usedSlots == 2) 

D 

65 

0 

5 

12 

putPtr = (putPtr + 1) % 3; 

A2 

100 

100 


13 

array [putPrt] = x ; 




6 

13 

putPtr = putPtr y, 3; 

A2 

100 

100 

7 

13 

putPtr = (putPtr + 1) % 2; 

A2 

56 

0 


28 

getPtr = (getPtr + 1) % 2; 




8 

14 

if (usedSlots == 3) notifyAllO; 

D 

33 

100 

9 

14 

remove: 

D 

55 

100 



tf (usedSlots 0) notifyAllO; 




10 

14 

usedSlots++ ; 

D 

35 

100 


15 

if (usedSlots == 0) notifyAllO; 




ir 

14 

if (usedSlots == 0) notifyO; 

D 

2 

100 


29 

if (usedSlots == 3) notifyO; 




12 

20 

while (usedSlots == 0) 

D 

100 

100 

13 

23 

if (usedSlots != 0) { 

Al, D 

100 

100 

14 

23 

if (halted) { 

Al 

3 

0 

15 

29 

if (usedSlots == 0) notifyAllO; 

D 

50 

0 

16 

29 

remove: 

D 

44 

0 



(if usedSlots —= 3) notifyAll(); 




17 

29 

usedSlots-" ; 

D 

66 

0 


30 

if (usedSlots == 3) notifyAllO; 




18 

30 

usedSlots++ 

Al, A2 

100 

100 

19 

35 

remove: 

D 

100 

100 



halted = true; 




20" 

36 

notifyO ; 

D 

2 

100 

21 

36 

remove: 

D 

100 

100 



notifyAllO; 
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consumer gets the value in position 0, etc. The consumer 
only gets the first three values. The producer then fin- 
ishes and sets the halted flag, where after the consumer 
now gets an exception when trying to get the fourth 
value (in position 0). Therefore the consumer will miss 
three values, and the first assertion (count == 6) will 
be broken. Note that the second assertion is not broken. 

Adding these print statements requires thought and 
work, but the idea may in fact be useful to cut down the 
enormous amount of information contained in the error 
traces created by Spin. 


5 Conclusion and Future Work 


Fig. 28. Trace for error 14 


are not guaranteed to be caught when plainly execut- 
ing the program on the newest version of JVM, while in 
contrast JPF finds the errors each time if present in the 
setup (errors 11 and 20 were not present with only one 
consumer). The difference is most obvious for errors 11, 
14 and 20. Errors 3 and 11 were suggested by a reviewer. 
The chance of catching errors by executing the program 
gets even smaller when the program size increases. ■ 

%.S Ervof Traces 

When Spin identifies an error in the translated Promela 
;code, be it a deadlock or an assertion violation, it returns ' 
with an error trace showing the sequence of executed 
Promela statements leading from the initial state to 
the state where the error occurs. Our tool does not cur- 
rently map such Promela error traces back to corre- 
sponding Java traces. As an alternative, we have ex- 
tended the Verify class with, special print methods 
which can be called (by the programmer) in selected 
places in the Java code. These calls will then be trans- 
lated into Promela print statements set up to print 
on a graphical two dimensional message sequence chart 
Figure 28 shows such a chart illustrating the trace for 
error number 14. 

To obtain this chart, to be explained below, we have 
added print statements 5 places in the code. For exam- 
ple, in lines 12 and 26 (pushing current lines downwards) 
we have added the statements: 

12 Verify .print(*'put",putPtr) ; 

26 Verify .printC'get” ,getPtr) ; 

Hence, what will be printed out is a text string (”put" 
or "get”), and the position in the buffer where a value 
is stored (put), respectively retrieved from (get). Other 
print statements record other events, such as the pro- 
ducer setting the halted flag, and the consumer getting 
the corresponding exception. Figure 28 illustrates a situ- 
ation where the producer (center vertical line) first pro- 
duces two values, stored in positions 0 and 1. Then the 


In this paper we have described the initial prototype of 
a translator from a noii-trivial subset of the general pur- 
pose programming language Java to the model checking 
language Promela. We have also applied the transla- 
tor to 21 bugged variations of a small example program, 
observing that the model checker catches all the bugs, 
while executing the programs only catch the bugs safely 
in half of the cases. 

We are currently applying tlie translator to a collec- 
tion of real programs developed within NASA, and the 
outcome of these experiments will be published at a later 
time. As an example, a collaboration with NASA’s God- 
dard Space Center involves the verification of a satellite 
file down-link protocol written in Java. The translator 
has in addition been applied to analyze a Chinese Chess 
game server application written in Java. This lead to 
the confirmation of a suspected deadlock and the iden- 
tification of a smaller scenario leading to that deadlock. 
This work is documented in [13]. 

Although the translator covers a non-trivial subset 
of Java some important features are not covered. These 
are: packages, overloading, method overriding, recursion, 
strings, floating point numbers, static variables and meth- 
ods, some thread operations like suspend and resume, 
some control constructs, such as the continue state- 
ment, and garbage collection. In addition, arrays are 
not objects as they are in Java. W’e model arrays us- 
ing Promela’s own arrays to obtain efficient verifica- 
tion. The current implementation thus does not allow 
arrays to be first class values and they cannot be multi- 
dimensional. Finally, we do not translate the predefined 
class library. Some of these features are hard to trans- 
late, such as recursion, strings, floating point numbers, 
and garbage collection. The rest are relatively straight 
forward, although an efficient translation of dynamic ar- 
rays as objects is not evident. We continue to extend the 
translator to cover more of Java. 

An essential question is whether the translation is 
optimal. We still need to evaluate this question. There 
may be other ways to translate into Promela and one 
may consider making a by-pass, avoiding Promela, and 
translating directly into the C interface to the Spin model 



checker. A major point of discussion has been how to 
model object creation. One obvious solution would be 
to use Promela’s proctypes to model classes, and then 
spawn a process for each object creation. This would in- 
deed help at the level of memory allocation and result in 
a simpler translation than into arrays. However, it con- 
flicts with the fact that several threads can access the 
same object concurrently: a Promela process only has 
one thread of control. 

Recently JPF has been modified to translate object 
synchronizations and exceptions more efficiently by in- 
troducing two new special purpose arrays holding lock- 
ing and exception variables, thus keeping these variables 
separate from user defined variables. This gave a 50% 
reduction in the amount of C-code generated by Spin. 
We have presented the simpler solution for readability 
reasons. 

We see the current translator as a phase 1 proto- 
type experiment (involving 9 man months until now) 
that provides us with useful input to a phase 2, where 
these questions will be raised. What is equally impor- 
tant is our planned efforts to build an abstraction work- 
bench around Java, where programs can be reduced in 
size before model checking is applied. Techniques such 
as program slicing, abstract interpretation, and partial 
evaluation will have a great influence. 

We believe that the kind of technology presented in 
this paper, already as is, can be very useful for unit test- 
ing where one focuses on a single or a few classes, just 
as has demonstrated with the example. This requires 
setting up an aggressive environment consisting of a col- 
lection of threads which will “bombard” the unit with 
accesses. The technology is probably ready for this al- 
ready now, since there will typically not be a big need to 
cut down the state space. Finally, we believe that per- 
haps the technology can be useful for students learning 
to program in Java. 

Concerning the specification language, our main ap- 
proach has been not to extend the Java language but to 
express temporal properties as calls to methods defined 
in a special temporal logic class (the Verify class), all of 
whose methods are static (hence one does not need to in- 
stantiate the class to objects before calling the methods). 
In addition to the assert method one can for example 
imagine an always method, an eventually method, and 
basically include all of Spin’s linear temporal logic op- 
erators as methods, having boolean return types in ad- 
dition to boolean argument types, such that they can be 
composed. Calls of such methods will then generate Ltl 
formulae to be verified, referring to the position where 
they are called in the code. 
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